In a typical computing environment, it is reasonable for a user to expect the data to be stored on a storage device when a notification indicating the data has been stored is provided to the user. For example, if a software application running on a computer system issues input/output (I/O) operations (also referred to as “data blocks” or simply “I/Os”) and the user receives a notification indicating that the I/O operations (or the relevant transactions or processes) have been committed to a storage device, it would be reasonable on the user's part to expect that commitment. However, occasionally, the data said to have been stored on the storage device is not stored or only partially stored due to bugs in the software or due to hardware failure and consequently, the user is mislead. Several tests, such as testing power outages or disconnections from storage, have been employed to exercise corner cases to help expose, for example, software bugs in I/O paths (including system call interface, the file system, the block layer, and down to the device drivers or even drive firmware) and to guarantee that when the user is notified of data commitment, the data is in fact committed to the storage device where it can be preserved and accessed (such as after the power is resumed). However, these testing techniques are limited in approach, cumbersome, and inefficient, primarily due to their manual nature and thus, the potential for human error. These conventional testing techniques include pulling computer system and/or storage device power cables from power outlets, manually turning off power switches, or pulling cables from, for example, Small Computer System Interface (SCSI) devices.